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Abstract 


Constrained devices are nodes with limited processing power, storage 
space, and transmission capacities. In many cases, these devices do 
not provide user interfaces, and they are often intended to interact 
without human intervention. 


This document includes a collection of representative use Cases for 
authentication and authorization in constrained environments. These 
use cases aim at identifying authorization problems that arise during 
the life cycle of a constrained device and are intended to provide a 
guideline for developing a comprehensive authentication and 
authorization solution for this class of scenarios. 


Where specific details are relevant, it is assumed that the devices 


use the Constrained Application Protocol (CoAP) as a communication 
protocol. However, most conclusions apply generally. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7744. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction 


Constrained devices [RFC7228] are nodes with limited processing 
power, storage space, and transmission capacities. These devices are 
often battery-powered and in many cases do not provide user 
interfaces. 


Constrained devices benefit from being interconnected using Internet 
protocols. However, deploying common security protocols can 
sometimes be difficult because of device or network limitations. 
Regardless, adequate security mechanisms are required to protect 
these constrained devices, which are expected to be integrated in all 
aspects of everyday life, from attackers wishing to gain control over 
the device’s data or functions. 


This document comprises a collection of representative use cases for 
the application of authentication and authorization in constrained 
environments. These use cases aim at identifying authorization 
problems that arise during the life cycle of a constrained device. 
Note that this document does not aim at collecting all possible use 
cases. 


We assume that the communication between the devices is based on the 
Representational State Transfer (REST) architectural style, i.e., a 
device acts as a server that offers resources such as sensor data and 
actuators. The resources can be accessed by clients, sometimes 
without human intervention (M2M). In some situations, the 
communication will happen through intermediaries (e.g., gateways, 
proxies). 


Where specific detail is necessary, it is assumed that the devices 
communicate using CoAP [RFC7252], although most conclusions are 
generic. 


1. Terminology 


Readers are required to be familiar with the terms defined in 
[RFC7228]. 
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2s 


2a 


Use Cases 


This section includes the use cases; each use case first presents a 
general description of the application environment, then one or more 
specific use cases, and finally a summary of the authorization- 
related problems to be solved. The document aims at listing the 
relevant authorization problems and not to provide an exhaustive 
list. It might not be possible to address all of the listed problems 
with a single solution; there might be conflicting goals within or 
among some requirements. 


There are various reasons for assigning a function (client or server) 
to a device. The function may even change over time; e.g., the 
device that initiates a conversation is temporarily assigned the role 
of client, but could act as a server in another context. The 
definition of the function of a device in a certain use Case is not 
in scope of this document. Readers should be aware that there might 
be reasons for each setting and that endpoints might even have 
different functions at different times. 


1. Container Monitoring 


The ability of sensors to communicate environmental data wirelessly 
opens up new application areas. Sensor systems make it possible to 
continuously track and transmit characteristics such as temperature, 
humidity, and gas content while goods are transported and stored. 


Sensors in this scenario have to be associated with the appropriate 
pallet of the respective container. Sensors, as well as the goods, 
belong to specific customers. 


While in transit, goods often pass stops where they are transloaded 
to other means of transportation, e.g., from ship transport to road 
transport. 


Perishable goods need to be stored at a constant temperature and with 
proper ventilation. Real-time information on the state of the goods 
is needed by both the transporter and the vendor. Transporters want 
to prioritize goods that will expire soon. Vendors want to react 
when goods are spoiled to continue to fulfill delivery obligations. 


The Intelligent Container <http://www.intelligentcontainer.com> is an 
example project that explores solutions to continuously monitor 
perishable goods. 
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«1. Bananas for Munich 
A fruit vendor grows bananas in Costa Rica for the German market. It 
instructs a transport company to deliver the goods via ship to 


Rotterdam where they are picked up by trucks and transported to a 
ripening facility. A Munich supermarket chain buys ripened bananas 
from the fruit vendor and transports them from the ripening facility 
to the individual markets with their own company’s trucks. 


The fruit vendor’s quality management wants to assure the quality of 
their products; thus, it equips the banana boxes with sensors. The 
state of the goods is monitored consistently during shipment and 
ripening, and abnormal sensor values are recorded (U1.2). 
Additionally, the sensor values are used to control the climate 
within the cargo containers (U1.1, Ul.5, Ul.7). Therefore, the 
sensors need to communicate with the climate-control system. Since 
an incorrect sensor value leads to a wrong temperature, and thus to 
spoiled goods, the integrity of the sensor data must be assured 
(U1.2, U1.3). The banana boxes within a container will, in most 
cases, belong to the same owner. Adjacent containers might contain 
goods and sensors of different owners (Ul.1). 


The personnel that transloads the goods must be able to locate the 
goods meant for a specific customer (Ul.1, Ul.6, Ul.7). However, the 
fruit vendor does not want to disclose sensor information pertaining 
to the condition of the goods to other companies and therefore wants 
to assure the confidentiality of this data (U1.4). Thus, the 
transloading personnel is only allowed to access logistic information 
(U1.1). Moreover, the transloading personnel is only allowed to 
access the data for the time of the transloading (U1.8). 


Due to the high water content of the fruits, the propagation of radio 
waves is hindered, thus often inhibiting direct communication between 
nodes [Jedermann14]. Instead, messages are forwarded over multiple 
hops (U1.9). The sensors in the banana boxes cannot always reach the 
Internet during the journey (U1.10). Sensors may need to use relay 
stations owned by the transport company to connect to endpoints on 
the Internet. 


In the ripening facility bananas are stored until they are ready to 
be sold. The banana box sensors are used to control the ventilation 
system and to monitor the degree of ripeness of the bananas. Ripe 
bananas need to be identified and sold before they spoil (U1.2, 
U1.8). 


The supermarket chain gains ownership of the banana boxes when the 
bananas have ripened and are ready to leave the ripening facility. 
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Authorization Problems Summary 


Fruit vendors and container owners want to grant different 
authorizations for their resources and/or endpoints to 
different parties. 


The fruit vendor requires the integrity and authenticity of 
the sensor data that pertains to the state of the goods for 
climate control and to ensure the quality of the monitored 
recordings. 


The container owner requires the integrity and authenticity 
of the sensor data that is used for climate control. 


The fruit vendor requires the confidentiality of the sensor 
data that pertains the state of the goods and the 
confidentiality of location data, e.g., to protect them from 
targeted attacks from competitors. 


The fruit vendor may need different protection for several 
different types of data on the same endpoint, e.g., sensor 
data and the data used for logistics. 


The fruit vendor and the transloading personnel require the 
authenticity and integrity of the data that is used to locate 
the goods, in order to ensure that the goods are correctly 
treated and delivered. 


The container owner and the fruit vendor may not be present 
at the time of access and cannot manually intervene in the 
authorization process. 


The fruit vendor, container owner, and transloading company 
want to grant temporary access permissions to a party, in 
order to avoid giving permanent access to parties that are no 
longer involved in processing the bananas. 


The fruit vendor, container owner, and transloading company 
want their security objectives to be achieved, even if the 
messages between the endpoints need to be forwarded over 
multiple hops. 


The constrained devices might not always be able to reach the 
Internet but still need to enact the authorization policies 
of their principals. 


Fruit vendors and container owners want to be able to revoke 
authorization on a malfunctioning sensor. 
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2.2. Home Automation 


One application of the Internet of Things is home automation systems. 
Such a system can connect household devices that control, for 
example, heating, ventilation, lighting, home entertainment, and home 
security to the Internet making them remotely accessible and 
manageable. 


Such a system needs to accommodate a number of regular users 
(inhabitants, close friends, cleaning personnel) as well as a 
heterogeneous group of dynamically varying users (visitors, 
repairmen, delivery men). 


As the users are not typically trained in security (or even computer 
use), the configuration must use secure default settings, and the 
interface must be well adapted to novice users. 


2.2.1. Controlling the Smart Home Infrastructure 


Alice and Bob own a flat that is equipped with home automation 
devices such as HVAC and shutter control, and they have a motion 
sensor in the corridor that controls the light bulbs there (U2.5). 


Alice and Bob can control the shutters and the temperature in each 
room using either wall-mounted touch panels or an Internet connected 
device (e.g., a smartphone). Since Alice and Bob both have full-time 
jobs, they want to be able to change settings remotely, e.g., turn up 
the heating on a cold day if they will be home earlier than expected 
(U2.5). 


The couple does not want people in radio range of their devices, 
e.g., their neighbors, to be able to control them without 
authorization. Moreover, they don’t want burglars to be able to 
deduce behavioral patterns from eavesdropping on the network (U2.8). 


2.2.2. Seamless Authorization 


Alice buys a new light bulb for the corridor and integrates it into 
the home network, i.e., makes resources known to other devices in the 
network. Alice makes sure that the new light bulb and her other 
devices in the network get to know the authorization policies for the 
new device. Bob is not at home, but Alice wants him to be able to 
control the new device with his devices (e.g., his smartphone) 
without the need for additional administration effort (U2.7). She 
provides the necessary configurations for that (U2.9, U2.10). 
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2.2.3. Remotely Letting in a Visitor 


Alice and Bob have equipped their home with automated connected door- 
locks and an alarm system at the door and the windows. The couple 
can control this system remotely. 


Alice and Bob have invited Alice's parents over for dinner, but are 
stuck in traffic and cannot arrive in time; whereas Alice's parents 
are using the subway and will arrive punctually. Alice calls her 
parents and offers to let them in remotely, so they can make 


themselves comfortable while waiting (U2.1, U2.6). Then, Alice sets 
temporary permissions that allow them to open the door and shut down 
the alarm (U2.2). She wants these permissions to be only valid for 


the evening since she does not like it if her parents are able to 
enter the house as they see fit (U2.3, U2.4). 


When Alice’s parents arrive at Alice and Bob’s home, they use their 
smartphone to communicate with the door-lock and alarm system (U2.5, 


U2.9). The permissions Alice issued to her parents only allow 
limited access to the house (e.g., opening the door, turning on the 
lights). Certain other functions, such as checking the footage from 


the surveillance cameras, are not accessible to them (U2.3). 


Alice and Bob also issue similarly restricted permissions to e.g., 
cleaners, repairmen, or their nanny (U2.3). 


2.2.4. Selling the House 


Alice and Bob have to move because Alice is starting a new job. They 
therefore decide to sell the house and transfer control of all 
automated services to the new owners (U2.11). Before doing so, they 
want to erase privacy-relevant data from the logs of the automated 
systems, while the new owner is interested to keep some historic data 
e.g., pertaining to the behavior of the heating system (U2.12). At 
the time of transfer of ownership of the house, the new owners also 
want to make sure that permissions issued by the previous owners to 
access the house or connected devices (in the case where device 
management may have separate permissions from house access) are no 
longer valid (U2.13). 


2.2.5. Authorization Problems Summary 


U2.1: A home owner (Alice and Bob in the example above) wants to 
spontaneously provision authorization means to visitors. 


U2.2: A home owner wants to spontaneously change the home’s access 
control policies. 
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A home owner wants to apply different access rights for 
different users (including other inhabitants). 


The home owners want to grant access permissions to someone 
during a specified time frame. 


The smart home devices need to be able to securely 
communicate with different control devices (e.g., wall- 
mounted touch panels, smartphones, electronic key fobs, and 
device gateways). 


The home owner wants to be able to configure authorization 
policies remotely. 


Authorized users want to be able to obtain access with little 
effort. 


The owners of the automated home want to prevent unauthorized 
entities from being able to deduce behavioral profiles from 
devices in the home network. 


Usability is particularly important in this scenario since 
the necessary authorization related tasks in the life cycle 
of the device (commissioning, operation, maintenance, and 
decommissioning) likely need to be performed by the home 
owners who, in most cases, have little knowledge of security. 


Home owners want their devices to seamlessly (and in some 
cases even unnoticeably) fulfill their purpose. Therefore, 
the authorization administration effort needs to be kept at a 
minimum. 


Home owners want to be able to transfer ownership of their 
automated systems when they sell the house. 


Home owners want to be able to sanitize the logs of the 
automated systems when transferring ownership without 
deleting important operational data. 


When a transfer of ownership occurs, the new owner wants to 
make sure that access rights created by the previous owner 
are no longer valid. 


Personal Health Monitoring 


Personal health monitoring devices, i.e., eHealth devices, are 
typically battery-driven and located physically on or in the user to 
monitor some bodily function, such as temperature, blood pressure, or 
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pulse rate. These devices typically connect to the Internet through 
an intermediary base station, using wireless technologies and through 
this connection they report the monitored data to some entity, which 
may either be the user or a medical caregiver. 


Medical data has always been considered very sensitive, and therefore 
requires good protection against unauthorized disclosure. A 
frequent, conflicting requirement is the capability for medical 
personnel to gain emergency access, even if no specific access rights 
exist. As a result, the importance of secure audit logs increases in 
such scenarios. 


Since the users are not typically trained in security (or even 
computer use), the configuration must use secure default settings, 
and the interface must be well adapted to novice users. Parts of the 
system must operate with minimal maintenance. Especially frequent 
changes of battery are unacceptable. 


There is a plethora of wearable health monitoring technology and the 
need for open industry standards to ensure interoperability between 
products has lead to initiatives such as Continua Alliance 
<http://continuaalliance.org> and Personal Connected Health Alliance 
<http://www.pchalliance.org>. 


2.3.1. John and the Heart Rate Monitor 


John has a heart condition that can result in sudden cardiac arrests. 
He therefore uses a device called "HeartGuard" that monitors his 


heart rate and his location (U3.7). In the event of a cardiac 
arrest, it automatically sends an alarm to an emergency service, 
transmitting John’s current location (U3.1). Either the device has 


long-range connectivity itself (e.g., via GSM) or it uses some 
intermediary, nearby device (e.g., John’s smartphone) to transmit 
such an alarm. To ensure John’s safety, the device is expected to be 
in constant operation (U3.3, U3.6). 


The device includes an authentication mechanism to prevent other 
persons who get physical access to it from acting as the owner and 
altering the access control and security settings (U3.8). 


John can configure a list of people that get notified in an 
emergency, for example his daughter Jill. Furthermore, the device 
stores data on John’s heart rate, which can later be accessed by a 
physician to assess the condition of John’s heart (U3.2). 


However, John is a privacy-conscious person and is worried that Jill 


might use HeartGuard to monitor his location even when there is no 
emergency. Furthermore, he doesn’t want his health insurance to get 
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access to the HeartGuard data, or even to the fact that he is wearing 
a HeartGuard, since they might refuse to renew his insurance if they 
decided he was too great of a risk for them (U3.8). 


Finally, John, while being comfortable with modern technology and 
able to operate it reasonably well, is not trained in computer 
security. Therefore, he needs an interface for the configuration of 
the HeartGuard security that is easy to understand and use (U3.5). 
If John does not understand the meaning of a setting, he tends to 
leave it alone, assuming that the manufacturer has initialized the 
device to secure settings (U3.4). 


Note: Monitoring of some state parameter (e.g., an alarm button) and 
the position of a person also fits well into a nursing service 
context. This is particularly useful for people suffering from 
dementia, where the relatives or caregivers need to be notified of 
the whereabouts of the person under certain conditions. In that 
case, it is not the patient that decides about access. 


2.3.2. Authorization Problems Summary 


U3.1: The wearer of an eHealth device (John in the example above) 
wants to preconfigure special access rights in the context of 
an emergency. 


U3.2: The wearer of an eHealth device wants to selectively allow 
different persons or groups access to medical data. 


U3.3: Battery changes are very inconvenient and sometimes 
impractical, so battery life impacts on the authorization 
mechanisms need to be minimized. 


U3.4: Devices are often used with default access control settings 
that might threaten the security objectives of the device’s 
users. 


U3.5: Wearers of eHealth devices are often not trained in computer 
use, especially computer security. 


U3.6: Security mechanisms themselves could provide opportunities for 
denial-of-service (DoS) attacks, especially on the constrained 
devices. 

U3.7: The device provides a service that can be fatal for the wearer 


if it fails. Accordingly, the wearer wants the device to have 
a high degree of resistance against attacks that may cause the 
device to fail to operate partially or completely. 
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U3.8: The wearer of an eHealth device requires the integrity and 
confidentiality of the data measured by the device. 


2.4. Building Automation 


Buildings for commercial use such as shopping malls or office 
buildings nowadays are equipped increasingly with semi-automatic 
components to enhance the overall living quality and to save energy 
where possible. This includes for example heating, ventilation and 
air condition (HVAC) as well as illumination and security systems 
such as fire alarms. These components are being increasingly managed 
centrally in a Building and Lighting Management System (BLMS) by a 
facility manager. 


Different areas of these buildings are often exclusively leased to 
different companies. However, they also share some of the common 
areas of the building. Accordingly, a company must be able to 
control the lighting and HVAC system of its own part of the building 
and must not have access to control rooms that belong to other 
companies. 


Some parts of the building automation system such as entrance 
illumination and fire-alarm systems are controlled either by all 
parties together or by a facility-management company. 


2.4.1. Device Life Cycle 
2.4.1.1. Installation and Commissioning 


Installation of the building automation components often start even 
before the construction work is completed. Lighting is one of the 
first components to be installed in new buildings. A lighting plan 
created by a lighting designer provides the necessary information 
related to the kind of lighting devices (luminaires, sensors, and 
switches) to be installed along with their expected behavior. The 
physical installation of the correct lighting devices at the right 
locations are done by electricians based on the lighting plan. They 
ensure that the electrical wiring is performed according to local 
regulations and lighting devices, which may be from multiple 
manufacturers, are connected to the electrical power supply properly. 
After the installation, lighting can be used in a default out-of-box 
mode, e.g., at full brightness when powered on. After this step (or 
in parallel in a different section of the building), a lighting 
commissioner adds the devices to the building domain (U4.1) and 
performs the proper configuration of the lights as prescribed in the 
lighting plan. This involves, for example, grouping to ensure that 
light points react together, more or less synchronously (U4.8) and 
defining lighting scenes for particular areas of the building. The 
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commissioning is often done in phases, either by one or more 
commissioners, on different floors. The building lighting network at 
this stage may be in different network islands with no connectivity 
between them due to lack of the IT infrastructure. 


After this, other building components, like HVAC and security 
systems, are similarly installed by electricians and later 
commissioned by their respective domain professionals. Similar 
configurations related to grouping (U4.8) are required to ensure, 
e.g., HVAC equipment is controlled by the closest temperature sensor. 


For the building IT systems, the Ethernet wiring is initially laid 
out in the building according to the IT plan. The IT network is 
often commissioned after the construction is completed to avoid any 
damage to sensitive networking and computing equipment. The 
commissioning is performed by an IT engineer with additional switches 
(wired and/or wireless), IP routers, and computing devices. Direct 
Internet connectivity for all installed/commissioned devices in the 
building is only available at this point. The BLMS that monitors and 
controls the various building automation components is only connected 
to the field devices at this stage. The different network islands 
(for lighting and HVAC) are also joined together without any further 
involvement of domain specialists, such as lighting or HVAC 
commissioners. 


2.4.1.2. Operational 


The building automation system is now finally ready, and the 
operational access is transferred to the facility management company 
of the building (U4.2). The facility manager is responsible for 
monitoring and ensuring that the building automation system meets the 
needs of the building occupants. If changes are needed, the 
facility-management company hires an external installation and 
commissioning company to perform the changes. 


Different parts of the building are rented out to different companies 
for office space. The tenants are provided access to use the 
automated HVAC, lighting, and physical access control systems 
deployed. The safety of the occupants is also managed using 
automated systems, such as a fire-alarm system, which is triggered by 
several smoke detectors that are spread out across the building. 


Company A’s staff moves into the newly furnished office space. Most 
lighting is controlled by presence sensors that control the lighting 
of a specific group of lights based on the authorization rules in the 
BLMS. Additionally, employees are allowed to manually override the 
lighting brightness and color in their offices by using the switches 
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or handheld controllers. Such changes are allowed only if the 
authorization rules exist in the BLMS. For example, lighting in the 
corridors may not be manually adjustable. 


At the end of the day, lighting is dimmed or switched off if no 
occupancy is detected, even if manually overridden during the day. 


On a later date, Company B also moves into the same building, and 
shares some of the common spaces and associated building automation 
components with Company A (U4.2, U4.9). 


2.4.1.3. Maintenance 


Company A’s staff is annoyed that the lighting switches off too often 
in their rooms if they work silently in front of their computers. 
Company A notifies the facility manager of the building to increase 
the delay before lights switch off. The facility manager can either 
configure the new values directly in the BLMS or, if additional 
changes are needed on the field devices, hire commissioning Company C 
to perform the needed changes (U4.4). 


Company C gets the necessary authorization from the facility- 
management company to interact with the BLMS. The commissioner’s 
tool gets the necessary authorization from the BLMS to send a 
configuration change to all lighting devices in Company A’s offices 
to increase the delay before they switch off. 


At some point, the facility-management company wants to update the 
firmware of lighting devices in order to eliminate software bugs. 
Before accepting the new firmware, each device checks the 
authorization of the facility-management company to perform this 
update (U4.13). 


A network-diagnostic tool of the BLMS detects that a luminaire in one 
of Company A's offices is no longer connected to the network. The 
BLMS alerts the facility manager to replace the luminaire. The 
facility manager replaces the old broken luminaire and informs the 
BLMS of the identity (e.g., the Media Access Control (MAC) address) 
of the newly added device. Then, the BLMS authorizes the new device 
in the system and seamlessly transfers all the permissions of the 
previous broken device to the replacement device (U4.12). 
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2.4.1.4. Recommissioning 


A vacant area of the building has recently been leased to Company A. 
Before moving into its new office, Company A wishes to replace the 
lighting with more energy efficient and better light quality 
luminaries. They hire an installation and commissioning Company C to 
redo the illumination. Company C is instructed to integrate the new 
lighting devices, which may be from multiple manufacturers, into the 
existing lighting infrastructure of the building, which includes 
presence sensors, switches, controllers, etc. (U4.1). 


Company C gets the necessary authorization from the facility- 
management company to interact with the existing BLMS (U4.4). To 
prevent disturbance to other occupants of the building, Company C is 
provided authorization to perform the commissioning only during non- 
office hours and only to modify configuration on devices belonging to 
the domain of Company A’s space (U4.5). Before removing existing 
devices, all security and configuration material that belongs to the 
domain is deleted and the devices are set back to factory state 
(U4.3). This ensures that these devices may be reused at other 
installations or in other parts of the same building without 
affecting future operations. After installation (wiring) of the new 
lighting devices, the commissioner adds the devices into Company A’s 
lighting domain. 


Once the devices are in the correct domain, the commissioner 
authorizes the interaction rules between the new lighting devices and 
existing devices, like presence sensors (U4.7). For this, the 
commissioner creates the authorization rules on the BLMS that define 
which lights form a group and which sensors/switches/controllers are 
allowed to control which groups (U4.8). These authorization rules 
may be context based, like time of the day (office or non-office 
hours) or location of the handheld lighting controller, etc. (U4.5). 


2.4.1.5. Decommissioning 


Company A has noticed that the handheld controllers are often 
misplaced and hard to find when needed. So most of the time, staff 
use the existing wall switches for manual control. Company A decides 
it would be better to completely remove handheld controllers and asks 
Company C to decommission them from the lighting system (U4.4). 


Company C again gets the necessary authorization from the facility- 
management company to interact with the BLMS. The commissioner now 
deletes any rules that allowed handheld controllers authorization to 
control the lighting (U4.3, U4.6). Additionally, the commissioner 
instructs the BLMS to push these new rules to prevent cached rules at 
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the end devices from being used. Any cryptographic key material 
belonging to the site in the handheld controllers is also removed, 
and they are set to the factory state (U4.3). 


2.4.2. Public Safety 


As part of the building safety code, the fire department requires 
that the building have sensors that sense the level of smoke, heat, 
etc., when a fire breaks out. These sensors report metrics that are 
then used by a back-end server to map safe areas and unsafe areas 
within a building and possibly the structural integrity of the 
building before firefighters may enter it. 

Sensors may also be used to track where human/animal activity is 
within the building. This will allow people stuck in the building to 
be guided to safer areas and allow the suggestion of possible actions 
that they may take (e.g., using a client application on their phones 
or giving loudspeaker directions) in order to bring them to safety. 
In certain cases, other organizations such as the police, ambulance, 
and federal organizations are also involved and therefore the co- 
ordination of tasks between the various entities have to be carried 
out using efficient messaging and authorization mechanisms. 


2.4.2.1. A Fire Breaks Out 


James, who works for Company A, turns on the air conditioning in his 
office on a really hot day. Lucy, who works for Company B, wants to 
make tea using an electric kettle. After she turns it on, she goes 
outside to talk to a colleague until the water is boiling. 
Unfortunately, her kettle has a malfunction that causes overheating 
and results in a smoldering fire of the kettle's plastic case. 


Due to the smoke coming from the kettle, the fire alarm is triggered. 
Alarm sirens throughout the building are switched on simultaneously 
(using a group communication scheme) to alert the staff of both 
companies (U4.8). Additionally, the ventilation system of the whole 
building is closed off to prevent the smoke from spreading and to 
withdraw oxygen from the fire. The smoke cannot get into James” 
office, even though he turned on his air conditioning, because the 
fire alarm overrides the manual setting by sending commands (using 
group communication) to switch off all the air conditioning (U4.10). 


The fire department is notified of the fire automatically and arrives 
within a short time. They automatically get access to all parts of 
the building according to an emergency authorization policy (U4.4, 
U4.5). After inspecting the damage and extinguishing the smoldering 
fire, a firefighter resets the fire alarm because only the fire 
department is authorized to do that (U4.4, U4.11). 
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Authorization Problems Summary 


During commissioning, the building owner or the companies add 
new devices to their administrative domain. Access control 
should then apply to these devices seamlessly. 


During a handover, the building owner or the companies 
integrate devices that formerly belonged to a different 
administrative domain to their own administrative domain. 
Access control of the old domain should then cease to apply, 
with access control of the new domain taking over. 


During decommissioning, the building owner or the companies 
remove devices from their administrative domain. Access 
control should cease to apply to these devices and relevant 
credentials need to be erased from the devices. 


The building owner and the companies want to be able to 
delegate specific access rights for their devices to others. 


The building owner and the companies want to be able to 
define context-based authorization rules. 


The building owner and the companies want to be able to 
revoke granted permissions and delegations. 


The building owner and the companies want to allow authorized 
entities to send data to their endpoints (default deny). 


The building owner and the companies want to be able to 
authorize a device to control several devices at the same 
time using a group communication scheme. 


The companies want to be able to interconnect their own 
subsystems with those from a different operational domain 
while keeping the control over the authorizations (e.g., 
granting and revoking permissions) for their endpoints and 
devices. 


The authorization mechanisms must be able to cope with 
extremely time-sensitive operations that have to be carried 
out quickly. 


The building owner and the public safety authorities want to 
be able to perform data origin authentication on messages 
sent and received by some of the systems in the building. 
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U4.12: The building owner should be allowed to replace an existing 
device with a new device providing the same functionality 
within their administrative domain. Access control from the 
replaced device should then apply to these new devices 
seamlessly. 


U4.13: When software on a device is updated, this update needs to be 
authenticated and authorized. 


2.5. Smart Metering 


Automated measuring of customer consumption is an established 
technology for electricity, water, and gas providers. Increasingly, 
these systems also feature networking capability to allow for remote 
management. Such systems are in use for commercial, industrial, and 
residential customers and require a certain level of security, in 
order to avoid economic loss to the providers, vulnerability of the 
distribution system, as well as disruption of services for the 
customers. 


The smart metering equipment for gas and water solutions is battery- 
driven and communication should be used sparingly due to battery 
consumption. Therefore, these types of meters sleep most of the 
time, and only wake up every minute/hour to check for incoming 
instructions. Furthermore, they wake up a few times a day (based on 
their configuration) to upload their measured metering data. 


Different networking topologies exist for smart metering solutions. 

Based on environment, regulatory rules, and expected cost, one or a 

mixture of these topologies may be deployed to collect the metering 

information. Drive-by metering is one of the most current solutions 
deployed for collection of gas and water meters. 


Various stakeholders have a claim on the metering data. Utility 
companies need the data for accounting, the metering equipment may be 
operated by a third-party service operator who needs to maintain it, 
and the equipment is installed in the premises of the consumers, 
measuring their consumption, which entails privacy questions. 


2.5.1. Drive-By Metering 


A service operator offers smart metering infrastructures and related 
services to various utility companies. Among these is a water 
provider, who in turn supplies several residential complexes ina 
city. The smart meters are installed in the end customer’s homes to 
measure water consumption and thus generate billing data for the 
utility company. They can also be used to shut off the water if the 
bills are not paid (U5.1, U5.3). The meters do this by sending and 
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receiving data to and from a base station (U5.2). Several base 
stations are installed around the city to collect the metering data. 
However, in the denser urban areas, the base stations would have to 


be installed very close to the meters. This would require a high 
number of base stations and expose this more expensive equipment to 
manipulation or sabotage. The service operator has therefore chosen 


another approach, which is to drive around with a mobile base station 
and let the meters connect to that in regular intervals in order to 
gather metering data (U5.4, U5.6, U5.8). 


2.5.2. Meshed Topology 


In another deployment, the water meters are installed in a building 
that already has power meters installed, the latter are mains 
powered, and are therefore not subject to the same power saving 
restrictions. The water meters can therefore use the power meters as 
proxies, in order to achieve better connectivity. This requires the 
security measures on the water meters to work through intermediaries 
(U5.9). 


2.5.3. Advanced Metering Infrastructure 


A utility company is updating its old utility distribution network 
with advanced meters and new communication systems, known as an 
Advanced Metering Infrastructure (AMI). AMI refers to a system that 
measures, collects, and analyzes usage, and interacts with metering 
devices such as electricity meters, gas meters, heat meters, and 
water meters, through various communication media either on request 
(on-demand) or on predefined schedules. Based on this technology, 
new services make it possible for consumers to control their utility 
consumption (U5.2, U5.7) and reduce costs by supporting new tariff 
models from utility companies, and more accurate and timely billing. 
However, the end consumers do not want unauthorized persons to gain 
access to this data. Furthermore, the fine-grained measurement of 
consumption data may induce privacy concerns, since it may allow 
others to create behavioral profiles (U5.5, U5.10). 


The technical solution is based on levels of data aggregation between 
smart meters located at the consumer premises and the Meter Data 
Management (MDM) system located at the utility company (U5.9). For 
reasons of efficiency and cost, end-to-end connectivity is not always 
feasible, so metering data is stored and aggregated in various 
intermediate devices before being forwarded to the utility company, 
and in turn accessed by the MDM. The intermediate devices may be 
operated by a third-party service operator on behalf of the utility 
company (U5.7). One responsibility of the service operator is to 
make sure that meter readings are performed and delivered in a 
regular, timely manner. An example of a Service Level Agreement 
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between the service operator and the utility company is, for example, 
at least 95% of the meters have readings recorded during the last 72 


hours. 
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Authorization Problems Summary 


Devices are installed in hostile environments where they are 
physically accessible by attackers (including dishonest 
customers). The service operator and the utility company 
want to make sure that an attacker cannot use data from a 
captured device to attack other parts of their 
infrastructure. 


The utility company wants to control which entities are 
allowed to send data to, and read data from, their endpoints. 


The utility company wants to ensure the integrity of the data 
stored on their endpoints. 


The utility company wants to protect such data transfers to 
and from their endpoints. 


Consumers want to access their own usage information and also 
prevent unauthorized access by others. 


The devices may have intermittent Internet connectivity but 
still need to enact the authorization policies of their 
principals. 


Neither the service operator nor the utility company are 
always present at the time of access and cannot manually 
intervene in the authorization process. 


When authorization policies are updated it is impossible, or 
at least very inefficient to contact all affected endpoints 
directly. 


Authorization and authentication must work even if messages 
between endpoints are stored and forwarded over multiple 
nodes. 


Consumers may not want the service operator, the utility 
company or others to have access to a fine-grained level of 
consumption data that allows the creation of behavioral 
profiles. 
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2.6. Sports and Entertainment 


In the area of leisure-time activities, applications can benefit from 
the small size and weight of constrained devices. Sensors and 
actuators with various functions can be integrated into fitness 
equipment, games, and even clothes. Users can carry their devices 
around with them at all times. 


Usability is especially important in this area since users will often 
want to spontaneously interconnect their devices with others. 
Therefore, the configuration of access permissions must be simple and 
fast and not require much effort at the time of access. 


Continuously monitoring allows authorized users to create behavioral 
or movement profiles, that correspond to the devices” intended use, 
and unauthorized access to the collected data would allow an attacker 
to create the same profiles. 

Moreover, the aggregation of data can seriously increase the impact 
on the privacy of the users. 


2.6.1. Dynamically Connecting Smart Sports Equipment 


Jody is an enthusiastic runner. To keep track of her training 
progress, she has smart running shoes that measure the pressure at 
various points beneath her feet to count her steps, detect 
irregularities in her stride, and help her to improve her posture and 
running style. On a sunny afternoon, she goes to the Finnbahn track 
near her home to work out. She meets her friend Lynn, who shows her 
the smart fitness watch she bought a few days ago. The watch can 
measure the wearer’s pulse, show speed and distance, and keep track 
of the configured training program. The girls realize that the watch 
can be connected with Jody’s shoes and can display the information 
the shoes provide. 


Jody asks Lynn to let her try the watch and lend it to her for the 
afternoon. Lynn agrees, but she doesn’t want Jody to access her 
training plan (U6.4). She configures the access policies for the 
watch so that Jody’s shoes are allowed to access the display and 
measuring features but cannot read or add training data (U6.1, U6.2). 
Jody’s shoes connect to Lynn’s watch at the press of a button, 
because Jody already configured access rights for devices that belong 
to Lynn a while ago (U6.3). Jody wants the device to report the data 
back to her fitness account while she borrows it, so she allows it to 
access her account temporarily. 


After an hour, Jody gives the watch back and both girls terminate the 
connection between their devices. 
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2.6.2. Authorization Problems Summary 


U6.1: Sports equipment owners want to be able to grant access rights 
dynamically when needed. 


U6.2: Sports equipment owners want the configuration of access 
rights to work with very little effort. 


U6.3: Sports equipment owners want to be able to preconfigure access 
policies that grant certain access permissions to endpoints 
with certain attributes (e.g., endpoints of a certain user) 
without additional configuration effort at the time of access. 


U6.4: Sports equipment owners want to protect the confidentiality of 
their data for privacy reasons. 


2.7. Industrial Control Systems 


Industrial control systems (ICS) and especially supervisory control 
and data acquisition systems (SCADA) use a multitude of sensors and 
actuators in order to monitor and control industrial processes in the 
physical world. Example processes include manufacturing, power 
generation, and refining of raw materials. 


Since the advent of the Stuxnet worm, it has become obvious to the 
general public how vulnerable these kind of systems are, especially 
when connected to the Internet [Karnouskos11]. The severity of these 
vulnerabilities are exacerbated by the fact that many ICS are used to 
control critical public infrastructure, such as nuclear power, water 
treatment, or traffic control. Nevertheless, the economical 
advantages of connecting such systems to the Internet can be 
significant if appropriate security measures are put in place (U7.5). 


2.7.1. Oil Platform Control 


An oil platform uses an industrial control system to monitor data and 
control equipment. The purpose of this system is to gather and 
process data from a large number of sensors and control actuators 
such as valves and switches to steer the oil extraction process on 
the platform. Raw data, alarms, reports, and other information are 
also available to the operators, who can intervene with manual 
commands. Many of the sensors are connected to the controlling units 
by direct wire, but the operator is slowly replacing these units by 
wireless ones, since this makes maintenance easier (U7.4). 


Some of the controlling units are connected to the Internet, to allow 
for remote administration, since it is expensive and inconvenient to 
fly in a technician to the platform (U7.3). 
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The main interest of the operator is to ensure the integrity of 
control messages and sensor readings (U7.1). Access in some cases 
needs to be restricted, e.g., the operator wants wireless actuators 
only to accept commands by authorized control units (U7.2). 


The owner of the platform also wants to collect auditing information 
for liability reasons (U7.1). 


Different levels of access apply e.g., for regular operators vs. 
maintenance technician vs. auditors of the platform (U7.6). 


2.7.2. Authorization Problems Summary 


U7.1: The operator of the platform wants to ensure the integrity and 
confidentiality of sensor and actuator data. 


U7.2: The operator wants to ensure that data coming from sensors and 
commands sent to actuators are authentic. 


U7.3: Some devices do not have direct Internet connection, but they 
still need to implement current authorization policies. 


U7.4: Devices need to authenticate the controlling units, especially 
those using a wireless connection. 


U7.5: The execution of unauthorized commands or the failure to 
execute an authorized command in an ICS can lead to 
significant financial damage and threaten the availability of 
critical infrastructure services. Accordingly, the operator 
wants authentication and authorization mechanisms that provide 
a very high level of security. 


U7.6: Different users should have different levels of access to the 
control system (e.g., operator vs. auditor). 


3. Security Considerations 


As the use cases listed in this document demonstrate, constrained 
devices are used in various environments. These devices are small 
and inexpensive and this makes it easy to integrate them into many 
aspects of everyday life. With access to vast amounts of valuable 
data and possible control of important functions, these devices need 
to be protected from unauthorized access. Protecting seemingly 
innocuous data and functions will lessen the possible effects of 
aggregation; attackers collecting data or functions from several 
sources can gain insights or a level of control not immediately 
obvious from each of these sources on its own. 
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Not only the data on the constrained devices themselves is 
threatened, the devices might also be abused as an intrusion point to 
infiltrate a network. Once an attacker gains control over the 
device, it can be used to attack other devices as well. Due to their 
limited capabilities, constrained devices appear as the weakest link 
in the network; hence, they pose an attractive target for attackers. 


This section summarizes the security problems highlighted by the use 
cases above and provides guidelines for the design of protocols for 
authentication and authorization in constrained RESTful environments. 


3.1. Attacks 


This document lists security problems that users of constrained 
devices want to solve. Further analysis of attack scenarios is not 
in scope of the document. However, there are attacks that must be 
considered by solution developers. 


Because of the expected large number of devices and their ubiquity, 
constrained devices increase the danger from Pervasive Monitoring 
[RFC7258] attacks. Solution Designers should consider this in the 
design of their security solution and provide for protection against 


this type of attack. In particular, messages containing sensitive 
data that are sent over unprotected channels should be encrypted if 
possible. 


Attacks aimed at altering data in transit (e.g., to perpetrate fraud) 
are a problem that is addressed in many web security protocols such 
as TLS or IPsec. Developers need to consider these types of attacks, 
and make sure that the protection measures they implement are adapted 
to the constrained environment. 


As some of the use cases indicate, constrained devices may be 
installed in hostile environments where they are physically 
accessible (see Section 2.5). Protection from physical attacks is 
not in the scope of this document, but it should be kept in mind by 
developers of authorization solutions. 


Denial-of-service (DoS) attacks threaten the availability of services 
a device provides and constrained devices are especially vulnerable 
to these types of attacks because of their limitations. Attackers 
Can illicit a temporary or, if the battery is drained, permanent 
failure in a service simply by repeatedly flooding the device with 
connection attempts; for some services (see Section 2.3), 
availability is especially important. Solution designers must be 
particularly careful to consider the following limitations in every 
part of the authorization solution: 


Seitz, et al. Informational [Page 25] 


REC 7744 ACE Use Cases January 2016 


Battery usage 
Number of required message exchanges 


Size of data that is transmitted (e.g., authentication and access 
control data) 


Size of code required to run the protocols 
Size of RAM memory and stack required to run the protocols 


Resources blocked by partially completed exchanges (e.g., while 
one party is waiting for a transaction time to run out) 


Solution developers also need to consider whether the session should 


be 


Seitz, 


protected from information disclosure and tampering. 
Configuration of Access Permissions 


The access control policies need to be enforced (all use cases): 
The information that is needed to implement the access control 
policies needs to be provided to the device that enforces the 
authorization and applied to every incoming request. 


A single resource might have different access rights for different 
requesting entities (all use cases). 


Rationale: In some cases, different types of users need different 
access rights, as opposed to a binary approach where the same 
access permissions are granted to all authenticated users. 


A device might host several resources where each resource has its 
own access control policy (all use cases). 


The device that makes the policy decisions should be able to 
evaluate context-based permissions such as location or time of 
access (see Sections 2.2, 2.3, and 2.4). Access may depend on 
local conditions, e.g., access to health data in an emergency. 
The device that makes the policy decisions should be able to take 
such conditions into account. 


Authorization Considerations 
Devices need to be enabled to enforce authorization policies 


without human intervention at the time of the access request (see 
Sections 2.1, 2.2, 2.4, and 2.5). 


et aly; Informational [Page 26] 


REC 7744 ACE Use Cases January 2016 


Seitz, 


Authorization solutions need to consider that constrained devices 
might not have Internet access at the time of the access request 
(see Sections 2.1, 2.3, 2.5, and 2.6). 


It should be possible to update access control policies without 
manually re-provisioning individual devices (see Sections 2.2, 
2.3, 2.5, and 2.6). 


Rationale: Peers can change rapidly which makes manual 
re-provisioning unreasonably expensive. 


Authorization policies may be defined to apply to a large number 
of devices that might only have intermittent connectivity. 
Distributing policy updates to every device for every update might 
not be a feasible solution (see Section 2.5). 


It must be possible to dynamically revoke authorizations (see 
Section 2.4 for example). 


The authentication and access control protocol can put undue 
burden on the constrained system resources of a device 
participating in the protocol. An authorization solution must 
take the limitations of the constrained devices into account (all 
use Cases, see also Section 3.1). 


Secure default settings are needed for the initial state of the 
authentication and authorization protocols (all use cases). 


Rationale: Many attacks exploit insecure default settings, and 
experience shows that default settings are frequently left 
unchanged by the end users. 


Access to resources on other devices should only be permitted if a 
rule exists that explicitly allows this access (default deny) (see 
Section 2.4 for example). 


Usability is important for all use cases. The configuration of 
authorization policies as well as the gaining access to devices 
must be simple for the users of the devices. Special care needs 
to be taken for scenarios where access control policies have to be 
configured by users that are typically not trained in security 
(see Sections 2.2, 2.3, and 2.6). 


Software updates are an important operation for which correct 
authorization is crucial. Additionally, authenticating the 
receiver of a software update is also important, for example, to 
make sure that the update has been received by the intended 
device. 
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3.4. Proxies 


In some cases, the traffic between endpoints might go through 
intermediary nodes (e.g., proxies, gateways). This might affect the 
function or the security model of authentication and access control 
protocols e.g., end-to-end security between endpoints with Datagram 
Transport Layer Security (DTLS) might not be possible (see 

Section 2.5). 


4. Privacy Considerations 


The constrained devices in focus of this document either collect data 
from the physical world via sensors or affect their surroundings via 
actuators. The collected and processed data often can be associated 
with individuals. Since sensor data may be collected and distributed 
on a regular interval, a significant amount of information about an 
individual can be collected and used as input for learning algorithms 
as part of big data analysis and used in an automated decision making 
process. 


Offering privacy protection for individuals is important to guarantee 
that only authorized entities are allowed to access collected data, 
to trigger actions, to obtain consent prior to the sharing of data, 
and to deal with other privacy-related threats outlined in RFC 6973. 


RFC 6973 was written as guidance for engineers designing technical 
solutions. For a short description about the deployment-related 
aspects of privacy and further references relevant for the Internet 
of Things sector, please see Section 7 of RFC 7452. 
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